Background: There have been several reports from DoD users about DoD certificate issues recently. The root of the issue is associate with DoD Root certificates chaining improperly to the (Federal Government) Common Policy Root Certificate Authority (CA). When this occurs on DoD systems, PKI validation does not work properly and may result in any of the following: 1. DoD user denied access to DoD web sites. 2. DoD users are unable to access DREN VPNs. 3. DoD signed emails in outlook appear invalid. 4. DoD users experience extensive delays with Outlook or Internet Explorer during validation. 5. DoD users receive a prompt to install the Common Policy Root CA when opening a signed email of a DoD sender whose workstation is misconfigured. . Issue: On November 23, 2009, Microsoft released an update KB931125 which updated the third-party certification authorities (CAs) that are trusted by Microsoft and whose root certificates are distributed via the Windows Root Certificate Program. The following certificates are the root cause: Thumbprint: dc92f91bab283472023b32178504e19bf7d9a94c Issuer/Subject: Iss: OU=Entrust, OU=FBCA Sub: OU=Entrust, OU=FBCA Thumbprint: 0a0e46657f4148df2d1c6778ea9308a8ca41989f Issuer/Subject: Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA Thumbprint: 3bae7b920ee6616755be4fa287777eef2f6b33f6 Issuer/Subject: Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA Thumbprint: dc92f91bab283472023b32178504e19bf7d9a94c Issuer/Subject: Iss: OU=Entrust, OU=FBCA Sub: CN=DoD Interoperability Root CA 1 Thumbprint: eea68fc8701e41e6429a341ae4162bbda634f7f4 Issuer/Subject: Iss: CN=DoD Interoperability Root CA 1 Sub: CN=DoD Root CA 2 Steps Taken so far: Step 1: DoD Administrators with workstations affected by this issue should decline all KB931125 updates in Windows Server Update Services 3.0. From the WSUS 3.0 manager console, search for " 931125". Right click the update and select Decline for all updates related to 931125. Step 2: DoD Administrators with workstations affected by this issue should remove the certificates below either with the DoD PKE tool or some other means. The DoD PKE "FBCA Cross-Certificate Removal Tool" is available from the following location: PKE on DKO: https://www.us.army.mil/suite/page/474113 under "Downloads" The following cross-certificates should be removed from the Local Computer and User Intermediate Certification Authority store: (DISA PKE Support) Common Policy Entrust (FBCA) cross-certificate Subject: OU=FBCA, OU=FBCA,O=U.S. Government,C=us Issuer: OU=Common Policy,OU=FBCA,O=U.S. Government,C=us Serial # 18 cc d6 6b 00 01 00 00 00 6f Valid To: Thursday, April 23, 2015 9:20:26 AM Common Policy Entrust (FBCA) cross-certificate (Revoked) Subject: OU=FBCA, OU=FBCA,O=U.S. Government,C=us Issuer: OU=Common Policy,OU=FBCA,O=U.S. Government,C=us Serial # 62 fa 21 6f 00 01 00 00 00 56 Valid To: Friday, March 21, 2014 12:25:49 PM Entrust (FBCA) IRCA cross-certificate Subject: CN=DoD Interoperability Root CA 1,OU=PKI,OU=DoD,O=U.S. Government,C=US Issuer: OU=Entrust,OU=FBCA,O=U.S. Government,C=US Serial # 45 1d e5 23 Valid To: Friday, December 31, 2010 12:00:00 AM IRCA DoD Root CA 2 cross-certificate Subject: CN=DoD Root CA 2, OU=PKI,OU=DoD,O=U.S. Government,C=US Issuer: CN=DoD Interoperability Root CA 1,OU=PKI,OU=DoD,O=U.S. Government,C=US Serial # 0C Valid To: Thursday, March 03, 2011 10:22:43 AM The following self-signed certificate(s) should be removed from the Local Computer and User Trusted Root Certification Authority store: Entrust (FBCA) self-signed certificate Subject: OU=Entrust,OU=FBCA,O=U.S. Government,C=US Issuer: OU=Entrust,OU=FBCA,O=U.S. Government,C=US Serial # 45 1d e1 72 (DISA PKE Support) For Domain Administrators , the tool can run on domain workstations using a Group Policy Startup script. First, a hidden share should be configured on a server to capture logs that the script was run. The hidden share should allow everyone to write to the share, checking both NTFS and Share permissions. In this example, the share was called "FBCA-log$". Create another shared folder called "FBCA_Crosscert_fix" with read-only permissions for all users. Next, create a new Group Policy Object named " Configuration: Remove CommonPolicy CA Script", the group policy should be applied to the entire domain to ensure the misconfigured Root CA certs are completely removed from the domain. Next, create a new Startup script named " FBCA-scriptremove.cmd" with the following scripts. @echo off IF EXIST \\servername\FBCA-log$\%computername%.txt goto end \\servername\FBCA_Crosscert_fix\FBCA_crosscert_remover_v104.exe /commonpolicy /s > \\servername\FBCA-log$\%computername%.txt :end Next, download the DoD PKE Cert Removal tool from: https://www.us.army.mil/suite/page/474113 and place FBCA_crosscert_remover_v104.exe in the \\servername\FBCA_Crosscert_fix\ share. Lastly, ensure that the " Turn off Automatic Root Certificates Update" setting is "Enabled" in Group Policy on the domain. This setting can be set under: Computer Configuration | Administrative Templates | System | Internet Communication Management | Internet Communication settings. Step 2a: Additional Requirement for Windows XP SP2 workstations In some cases, it has been reported the " Turn off Automatic Root Certificates Update" GPO setting does not stop Windows from updating the Root Certificates automatically. Two additional steps must be taken. First, the " FBCA-scriptremove.cmd" script must be modified to include code to uninstall the "Update Root Certificates" Windows component installed under Windows XP SP2 by default. The script should now look like this: The script should now look like this: @echo off IF EXIST \\servername\FBCA-log$\%computername%.txt goto end \\servername\FBCA_Crosscert_fix\FBCA_crosscert_remover_v104.exe /commonpolicy /s > \\servername\FBCA-log$\%computername%.txt :end IF EXIST \\ servername \FBCA-log$\%computername%_WXP-03-Uninst-Updt-Rt-Cert-Comp.txt goto end sysocmgr /i:%windir%\inf\sysoc.inf /u:\\servername\software\FBCA_Crosscert_fix\rootautoupdateuninstall.txt /q > \\ servername \FBCA-log$\%computername%_WXP-03-Uninst-Updt-Rt-Cert-Comp.txt :end In addition, the following text file named " rootautoupdateuninstall.txt" should be created, located in the same share that was created to store the FBCA_crosscert_remover_v104.exe utility. For example: \\servername\FBCA_Crosscert_fix\ " rootautoupdateuninstall.txt" should contain the following text. [components] rootautoupdate = off Validation: If everything is setup and working correctly, when hosts restart, they will run the script one time, and write two log files to the \\servername\FBCA-log$\ share. The first file will be named after the host. The file will contain a log of the results of the FBCA_crosscert_remover_v104.exe utility. The log will contain one of two outcomes. No certs were found: ##### FBCA cross-certificate removal tool ##### Created by DoD PKE Engineering January 2010 BACKGROUND: The DOD PKI PMO has discovered problems building certificate chains when the DoD Root and Intermediate certificates have not been properly installed. PROBLEM: Administrators must install the DoD Root and latest intermediate CA certificates on all workstations and servers. SYMPTOMS: Users can experience delays when performing operations with DoD PKI issued certificates. Inconsistent path building can occur where DoD PKI certificates chain up to the Common Policy root or cross-certificates mentioned below. CERTIFICATES: Thumbprint Issuer/Subject dc92f91bab283472023b32178504e19bf7d9a94c Iss: OU=Entrust, OU=FBCA Sub: OU=Entrust, OU=FBCA 0a0e46657f4148df2d1c6778ea9308a8ca41989f Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA 3bae7b920ee6616755be4fa287777eef2f6b33f6 Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA dc92f91bab283472023b32178504e19bf7d9a94c Iss: OU=Entrust, OU=FBCA Sub: CN=DoD Interoperability Root CA 1 eea68fc8701e41e6429a341ae4162bbda634f7f4 Iss: CN=DoD Interoperability Root CA 1 Sub: CN=DoD Root CA 2 RESOLUTION: * Disable the Microsoft Root Update Service (DISA STIG requirement) * Install the DoD Root and Intermediate CA certificates which can be done by running the latest version of InstallRoot (as an administrator). InstallRoot can be obtained from https://www.dodpke.com/installroot/ * Run this tool. DEPENDENCIES: * Microsoft Windows 2000 SP3 or newer Operating System * .NET Framework 2.0 or above USAGE: /COMMONPOLICY Additionally removes the Common Policy self-signed certificates /S Silent mode - doesn't require user to hit <ENTER>. NOTE: Administrative privileges are required to remove certificates from the LocalMachine store. Starting to search for certificates... Searching the LocalMachine Root certificate store...certificates not found. Searching the LocalMachine CA certificate store...certificates not found. Searching the LocalMachine My certificate store...certificates not found. Searching the CurrentUser Root certificate store...certificates not found. Searching the CurrentUser CA certificate store...certificates not found. Searching the CurrentUser My certificate store...certificates not found. Finished. Certs were found and removed: ##### FBCA cross-certificate removal tool ##### Created by DoD PKE Engineering January 2010 BACKGROUND: The DOD PKI PMO has discovered problems building certificate chains when the DoD Root and Intermediate certificates have not been properly installed. PROBLEM: Administrators must install the DoD Root and latest intermediate CA certificates on all workstations and servers. SYMPTOMS: Users can experience delays when performing operations with DoD PKI issued certificates. Inconsistent path building can occur where DoD PKI certificates chain up to the Common Policy root or cross-certificates mentioned below. CERTIFICATES: Thumbprint Issuer/Subject dc92f91bab283472023b32178504e19bf7d9a94c Iss: OU=Entrust, OU=FBCA Sub: OU=Entrust, OU=FBCA 0a0e46657f4148df2d1c6778ea9308a8ca41989f Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA 3bae7b920ee6616755be4fa287777eef2f6b33f6 Iss: CN=Common Policy, OU=FBCA Sub: OU=Entrust, OU=FBCA dc92f91bab283472023b32178504e19bf7d9a94c Iss: OU=Entrust, OU=FBCA Sub: CN=DoD Interoperability Root CA 1 eea68fc8701e41e6429a341ae4162bbda634f7f4 Iss: CN=DoD Interoperability Root CA 1 Sub: CN=DoD Root CA 2 RESOLUTION: * Disable the Microsoft Root Update Service (DISA STIG requirement) * Install the DoD Root and Intermediate CA certificates which can be done by running the latest version of InstallRoot (as an administrator). InstallRoot can be obtained from https://www.dodpke.com/installroot/ * Run this tool. DEPENDENCIES: * Microsoft Windows 2000 SP3 or newer Operating System * .NET Framework 2.0 or above USAGE: /COMMONPOLICY Additionally removes the Common Policy self-signed certificates /S Silent mode - doesn't require user to hit <ENTER>. NOTE: Administrative privileges are required to remove certificates from the LocalMachine store. Starting to search for certificates... Searching the LocalMachine Root certificate store... * FOUND Certificate: CN=Common Policy, OU=FBCA, O=U.S. Government, C=us Issuer : CN=Common Policy, OU=FBCA, O=U.S. Government, C=us Thumbprint : CB44A097857C45FA187ED952086CB9841F2D51B5 Serial: 293647AAE38AAC864A2356F2CAB761AF - Removing Certificate...SUCCESSFUL * FOUND Certificate: CN=Common Policy, OU=FBCA, O=U.S. Government, C=us Issuer : CN=Common Policy, OU=FBCA, O=U.S. Government, C=us Thumbprint : 76B76096DD145629AC7585D37063C1BC47861C8B Serial: 39E3815404C50AB247EFFEF336CFC698 - Removing Certificate...SUCCESSFUL Searching the LocalMachine CA certificate store...certificates not found. Searching the LocalMachine My certificate store...certificates not found. Searching the CurrentUser Root certificate store...certificates not found. Searching the CurrentUser CA certificate store...certificates not found. Searching the CurrentUser My certificate store...certificates not found. Finished. The second log file will be named after the host followed by " _WXP-03-Uninst-Updt-Rt-Cert-Comp.txt" If the host is running Windows XP or Server 2003, the Windows Component will be removed, and the following information will be logged. If the host is running Vista or above, the file will be blank. 401.339.0: 0x80070002 (WIN32: 2) 401.432.0: 0x80070002 (WIN32: 2) 401.1246.0: 0x80070002 (WIN32: 2): C:\WINDOWS\CAPolicy.inf 104.685.0: 0xe0000102 (INF: -536870654): Components 110.379.0: 0xe0000102 (INF: -536870654) 104.1282.0: 0xe0000102 (INF: -536870654) 104.2445.0: 0xe0000102 (INF: -536870654) 104.2436.0: 0xe0000102 (INF: -536870654) 104.2482.0: 0xe0000102 (INF: -536870654) 104.2482.0: 0xe0000102 (INF: -536870654) 104.2482.0: 0xe0000102 (INF: -536870654) 104.2587.0: 0xe0000102 (INF: -536870654) 104.2587.0: 0xe0000102 (INF: -536870654) 104.2587.0: 0xe0000102 (INF: -536870654) 104.2502.0: 0xe0000102 (INF: -536870654) 104.2502.0: 0xe0000102 (INF: -536870654) 104.2502.0: 0xe0000102 (INF: -536870654) The script will run one time, if the log files it creates remain present for subsequent logons. The script will not run if the domain is unavailable at boot. During logon when the script is working, the startup may take longer than usual. This should be a onetime occurrence to repair this issue. Problem: DisableRootAutoUpdate set to Enabled by doesn't seem to work for this case. Users are still finding their systems are being updated automatically with the "Common Policy Root CA" certificate.

Ok, I'll try that and get back to you in a few days. Thanks!

No luck, it was already set to 1. Any other suggestions? Thanks, Rob

Hi, As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios. If the issue still persists, please feel free to reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish. BTW, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems. Thanks for your understanding and efforts. Best Regards Dale

This definitely has NOT solved our issue. We have two goals: 1. We want to figure out how, and where this is coming from, as it seems to be automatic, and is by-passing the supposed controls to block this function. 2. We want a permanent fix to stop this action from happening completely, not a Band-Aid to block it when it happens. Is it possible for you to esculate this issue? In talking with our different organizations, we understand that many DoD Agencies and Organizataions have tickets in with Microsoft regarding this issue. This is a major issue for us, and we need resolution immediately. Thanks, Rob

I completely agree the first post is only a temporary fix. We have also seen the issues to discribed, and that the "bad" cert is reinstalled to recipents, when users with the "bad" cert installed send mail to clean users. Tell me more about the commercial websites you're having issues with, and needing these certs to work properly? The fix for us is for Microsoft to tell us how to block this auto install of these certificates.

This issue still has not been fixed...

Any updates on this? We are having this same issue with ALOT of different users... The problem only seems to be affecting users that are accessing our LAN from the VPN.... Any Ideas.... Thanks in advance...

Ive done a little research into this issue, and as best I can tell, DisableRootAutoUpdate / KB931125 are not the culprit. Without going into a lengthy discussion about what exactly is going on, let me provide two possible solutions. First option is to add the DoD Root CA 2 issued by DoD Interoperability Root CA 1 certificate into a domain-wide GPOs Untrusted Certificates container. Once the GPO is opened, navigate to Computer Configuration | Policies | Windows Settings | Security Settings | Public Key Policies | Untrusted Certificates. Into that container, import DoD Root CA 2 issued by DoD Interoperability Root CA 1. Second option is for DoD to revoke DoD Root CA 2 issued by DoD Interoperability Root CA 1. This will have the same effect as the first option, but will global fix the issue. Presumably, there was some reason why the certificate was created in the first place; so a management decision would need to be made if the value this certificate provides is worth the administrative overhead. Couple of notes. Both options will effectively prevent Windows from ever building a certificate chain that uses DoD Root CA 2 issued by DoD Interoperability Root CA 1. Thereby ensuring any CAC enabled website logons or new SMIME messages include the correct certificate chain. In addition, this will prevent the reoccurrence of this issue (i.e. when the user opens an email with the wrong chain). But, that also means those badly chained emails will show up as revoked. So before going through the process of global marking that certificate as untrusted, you should at least do a pilot deployment to detect any adverse effects. Last word of warning. While from a strictly technical perspective the above should fix the problems youre encountering; theres no way to fully predict the impact to an environment; nor can I offer any information about what (if any) DoD policies exist around this scenario. One addition to the above. Ive seen some tools/instructions which recommend untrusting Common Policy issued by Common Policy. If your organization interacts at all with the civilian government; I would advise against that. As the Common Policy root is the root which the PIV cards (civilian version of CAC) chain to. By untrusting that certificate; youll break S/MIME communication (in addition to smart card logon and SSL logon).